Academic Open Internet Journal

ISSN 1311-4360

www.acadjournal.com

Volume 22, 2008

 

 

 

Mobile Dynamic reconfigurable Context aware middleware for Adhoc smart spaces

 

 

Radhika.N, 

Research Scholar, 

Government College of Technology, 

Coimbatore -641 105 

Email: radhisai@yahoo.co.in

 

Dr. S.Arumugam

Additional Director

Directorate of Technical Education

Chennai

 

Abstract

 

 The aim of our paper is to design a mobile dynamic middleware for protocol interoperability in adhoc smart spaces. Smart spaces are composed of mobile devices, sensors, attenuators, both smart and dummy nodes and other wireless devices. The Protocols considered are service discovery protocols that seamlessly interoperate in the middleware. The purpose of interoperation is to make all the services on different smart spaces available to the user. The system considered here is a personalized system where the profile of the user is analyzed. and the request is seamlessly flooded in to the middleware. Among the available service the best matching service depending on the context of the user gets seamlessly adapted to the device of the user. The middleware has the feature to serve multiple users simultaneously on varying as well as on fixed context at the same time. The Middleware is termed mobile Adhoc as it is not attached to any infrastructure and is movable.

.

Keywords: Interoperability, Context aware, Middleware, smart space, seamlessly

 

1: Motivation

 

 The mobile middleware so far designed is context aware based on only one factor ie location. Our middleware is based on multiple-context factor. Secondly service discovery is one of the most important feature of the mobile context aware middleware.  Interoperability of service discovery protocols in the middleware along with the context information is a trivial problem which has not yet been solved. In this paper this is brought about in the application layer by creating a Dynamic reconfigurable context aware middleware. In out framework any service discovery protocol could be made to interoperate seamlessly without look up server. So far only jini architecture have been designed in the middleware. The disadvantage of this architecture is that it works in java platform. Moreover look up servers are maintained in jini architecture which require extra overhead. In order to minimize the cost of the heavy loaded lookup service seamless integration of protocols is considered in our architecture. More over Tuple space middleware systems discussed in literature only focused on individual smart spaces and interoperability of protocols on different smart spaces were not considered. Our work focuses on interoperability of protocols across smart spaces.

 

2: Introduction

 

 Middleware is connectivity software that joins applications through communication mechanisms creating transparency, scalability and interoperability and lies between software applications it assists and the platform it is based upon [1]. Smart spaces are termed as smart networks that have the capacity to fetch information from all other networks with the smart nodes embedded in the space. The personalized service is read as profile of the user and seamlessly integrated by the proactive/ reactive protocol in to the context aware middleware. The routing protocol is selected based on the context. If the decision of routing is taken prior to the routing then proactive protocol is chosen and if it is decided on the time of routing reactive protocol is chosen. It is at the middleware the context is matched and then routed in to the smart space.

 

 Three smart spaces are created – one space is created with sensors termed as sensor smart spaces, other space is considered to be adhoc i.e. without a fixed infrastructure  consisting

Of both smart and dummy nodes and other completely mobile. Each of the space runs on a service discovery protocol. These protocols interoperate in the middleware such that any personalized quest of service could be satisfied by the devices within the smart spaces.

 

3: Context Awareness

 

 Dey’s have defined context awareness as follows: A system is context aware if it uses the context to provide relevant information and or service to the user, where relevancy depends on the user’s task. Context awareness seeks to exploit human computer interaction by providing computing device with knowledge of user’s environment i.e. with context [3].

 

4: Context Aware middleware

 

 A dynamic reflective context aware middleware is designed which acts as a platform for the protocol to interoperate seamlessly. Different profile could be serviced at the same time . The services are arranged in the form of clusters in the smart space.Each smart space contains ‘n’ number of clusters and the number of clusters need not be uniform in all the spaces. 

 The cluster head is selected by choosing a node which remains in the network for a longer period of time. The node should also cover all other node in the network with a shorter distance and in a minimum time span. The third condition in selection of the cluster head node is that the node should offer almost similar service like any other node in the same cluster. The network considered here is a peer to peer system and each clusters act as peer systems. It need not be that all the nodes in the peer offer same service. Each nodes can offer similar or different services. Clustering of nodes is done by a group based clustering algorithm which has the properties to seamlessly fetch the nodes offering similar service within the cluster and among the cluster in the same smart space as well as on different smart space.

 

 

 

 

 

Fig 1: Context Aware Middleware

 

The service is fetched from the clusters with the service discovery protocol interoperability along with the group based protocol and is fed in to the middleware seamlessly by the proactive/ reactive protocol. The protocol is chosen here based on the context. The context varies based on location, environment and activity. For the same profile based on the context the choice and provision of service will differ. The middleware Component falls in to two categories: The mobile device based component provides an API to the application developer to spell out the location and context requirement for the required location based service [2] .

 

 The seamless interoperable component uses the service on behalf of the mobile client and returns the response to the device based on the context ie location, position and activity requirements.

 In our middleware we consider presently only slp/ sdp interoperability and this could be extended to other discovery protocols like jini, salutation etc. The main feature of our middleware is that there is no lookup table maintained in the protocols and the service is rendered seamlessly.

 

 5: Service Discovery Protocol

 

 Any service discovery protocol could be made to interoperate. The service discovery protocols considered in this paper are slp and sdp. Jini, salutation and upnp could also be added up to the architecture. Bluetooth is service discovery protocol used for short range of service.

 

5.1: SDP

 

 The service discovery protocol provides a means for applications to discovery which services are available and to determine the characteristics of available service. SDP is a simple protocol with minimal requirements on underlying transport. It can function over a reliable packet transport.SDP uses request/ response model where each transaction consists of one request protocol data unit and one response PDU. This is made to seamlessly interoperate in our model. Service can include common ones such as servicing, paging and faxing as well as different kind of information access such as tele- conferencing, network bridges and access points.

 

5.2: SLP

 

 SLP is used to access remote service as well as local service. SLP contains three agents user agent, Directory agent and service agent. The user agents here request for personalized service which is obtained from the Directory agent. Service Agent advertises the service in the Directory agent .The Services are prompted as alerts by the service agent. SLP is based on the knowledge of the SLP server where the client can address the service request. Further more the service provisioning has to register the SLP characteristics in the SLP server. Thus when the client accesses the server it will get all the service information in the service reply [4].

 

 

6. Routing Algorithms

 

 The routing protocols can be classified in to proactive and reactive routing Algorithms. Proactive routing protocol determines the path of transmission form source to destination in advance where as the reactive routing protocol determines the path only during the transmission. Eg of reactive protocols are AODV, DSDV that determines the path on the spot. proactive protocol has OLSR as an example. AODV is generally used in mobile networks and OLSR is used in adhoc networks [4].

 

 The choice of the proactive/ reactive protocol is done by the context sensitive feature of the middleware. If the route of seamless transmission is decided in advance then it follows a proactive transmission and when is done on demand then reactive routing scheme is followed. In our paper we consider using routing protocols only from the user requesting the service to the middleware and after the discovery in the middleware the information is routed back using the routing Algorithms.

 

7.Related work

 

7.1: Other middleware’s

 

 Traditional middleware like DCOM, CORBA deals with heterogeneous services and devices but are only capable of offering service to fixed devices. Traditional middleware failed to serve mobile applications. To support mobile applications four types of middleware were studied- Context aware, Tuple space, event based and reflective middleware. Reflective system support higher level of reflection since they can add and remove methods from objects and classes dynamically and can still alter the classes of objects at run time. Reflective middleware like Dynamic TAO and Flexi net are built around the concept of object oriented and component framework respectively. Tuple space system exploit the decoupled nature of tuple spaces for supporting disconnected operations in a natural manner. Traditional system follows a request/ reply style of communication. Event based system achieves a highly dynamic style of many to many interaction between client and server. Context aware system provides mobile applications with necessary knowledge about the execution context in order to allow the applications to adapt a dynamic change in the mobile host and network conditions. So far context aware applications are only focusing to user’s location while other things of interest are also mobile and changing. In general reflective system provides mobile application with context information that they need to optimize the middleware and its own information.[5].

 

But it was found that each of the middleware had its own negative feature and no step was made to combine all the positive feature of all this middleware to form a full fledged middleware system. In our middleware we combined the feature of both the smart space and

context awareness and our middleware supported the property of reflection and dynamism also. Our middleware brings about context awareness based on location, activity and the environmental condition thus bringing about dynamism rather than dealing with a single factor.

 Context awareness is obtained by sensing the personalized profile and finding out the context match in the middleware with the requested service. Protocol interoperability and smart nodes play an important role in bringing smart space together and also to relate the exact match of service.

 

 

8. Future work

 

The enrichment of the current work includes involving the web based searching including interoperability of all service discovery protocol like upnp, jini. This also includes searching at a remote location. Here the context is to be matched with the url and the necessary service is to be retrieved. One more enhancement feature is the security aspect which includes authentication and authorization of the profile. Asynchronous routing protocol like Asynchronous probabilistic protocol and delay tolerant routing protocol is also to be considered in interoperability to bring about communication even when the devices are not within the range or disappeared out of range of service.

 

 

9. Bibliography

 

 

[1] G.Micheal Youngblood, “Middleware”, University of Texas at Arlington.

[2] Sanket Pai, Dr. Lee YugYung , “A P2P based context aware middleware for mobile commerce Applications”.

[3] Patricia Dock horn Costa, “Towards a service platform for context Aware Applications” August 2003.

[4] Jose Costa – Requena, “Adhoc Routing Taxonomy and Resource Discovery”, 2002.

[5] Abdul basset Gaddah and Thomas Kunz, “A Survey of Middleware Paradigms for Mobile Computing”. July 2003.

[6] Yau, S.S.Karim, F.Wang, Y.Wang and Gupta, “Reconfigurable context sensitive middleware for pervasive computing”, IEEE Pervasive Computing.

 

eXTReMe Tracker

Technical College - Bourgas,

All rights reserved, © March, 2000